Markup languages, such as HTML, are currently the primary manner by which information is exchanged over the worldwide web (“the web”) of the Internet, or over related networks such as intranets and extranets. Markup languages in general provide a relatively rich assortment of functionality. Two example types of functionality that are relevant to one or more embodiments include: rendering behaviors, and layout behaviors. A behavior generally refers to an action, or processing, that can be performed in relation to a markup language element. An element in a markup language is a discrete entity that can be the combination of a set of markup language tags, any content contained between the tags, and any attributes the tags may have. Rendering behaviors generally are behaviors that specify how markup language elements are to be rendered, or drawn, on a medium, such as a display screen or on a printed page. Layout behaviors generally are behaviors that specify how markup language elements are to be laid out, or positioned and sized, on the medium.
Core engines that process markup languages, such as those found in web browsing computer programs and components of operating systems, do provide a rich assortment of behaviors for content authors. However, invariably the content authors may want to provide layout and rendering functionality that are not supported by the core engines. For example, the authors may want to position and size markup language elements in a way that is not supported by the core engine, or may want to draw the elements in a way that is not supported by the core engine. The prior art, however, only provides limited support for extensible behaviors. That is, the prior art only provides limited support for extended layout and rendering behaviors that are not supported by the core engine itself.
One way that extended behaviors are supported in the prior art is by using a technology known as a plug-in. Plug-ins are computer programs that can be called by the core engine to completely take over all the behaviors of an element associated with a plug-in, and that are referenced in HTML code. Plug-ins, while useful, have a significant disadvantage in that they take over processing of the element from the core engine on a wholesale basis. The core engine views a plug-in as a black box meant to process a given element or elements. The core engine does not participate in the processing of elements that are processed by the plug-in. Likewise, the plug-in cannot delegate some of the processing to the core engine. The plug-in represents an all-or-nothing affair: either the plug-in takes complete control of processing an element, without support from the core engine, or it does not. As such, the plug-in does not represent a complete solution to content authors' desire to extend behaviors supported by the core engine.
Another limited solution to provide extended behaviors in the prior art is by using dynamic HTML (DHTML) behaviors, which some prior art web browsing computer programs and operating system components support. DHTML behaviors are written similar to scripts, except that the DHTML behaviors can be separated from the HTML content itself. That is, while a script is integrated within the HTML content, a DHTML behavior is referenced within the HTML content. The DHTML behavior itself is still written as a script, but it is a script that is separate from the HTML content that references the behavior. Alternatively, the DHTML behaviors can be written in C++, a common computer programming language. DHTML behaviors are limited in the extensible behaviors that they can support. DHTML behaviors allow multiple HTML elements to be fused together as a single entity, and allow single HTML tags to be extended and enhanced. However, the DHTML behaviors ultimately only extend, enhance, or group together existing behaviors of the core engine. DHTML behaviors are more of a tool to supplement or group together existing behaviors supported by the core engine than a mechanism to develop radically new behaviors. That is, DHTML behaviors allow content authors to approach existing behaviors in a dynamic way, as opposed to creating new behaviors that may be based on, utilize, or otherwise participate with existing behaviors supported by the core engine.
A third approach supported by the prior art to extend behaviors is known as Object Linking and Embedding (OLE). OLE is not specific to markup languages, however. Rather, OLE allows binary software objects with well-defined properties and I/O interfaces to be reused. In the context of HTML, they can be referred to within HTML code in a similar manner to which plug-ins are referenced. While they provide full extensibility of existing behaviors of the core engine, they cannot participate with existing behaviors, but rather replace them, like plug-ins. As such a wholesale approach to behavior extensibility, OLE objects cannot be used to supplement existing behaviors in a minor, albeit subjectively important to the content author, way. OLE objects can be viewed as a plug-in-like technology, but which is based on software objects, instead of software programs, as plug-ins are.
Content authors, therefore, are currently presented with prior art extensibility of behaviors that may not represent how they actually want to extend those behaviors. Minor supplementation and aggregation of existing behaviors can be accomplished by using DHTML behaviors. Complete wholesale replacement of existing behaviors, and providing new behaviors without participation with existing behaviors, can be accomplished by using plug-ins or OLE objects. However, content authors cannot within the prior art provide extended behaviors that participate with existing behaviors beyond the limited supplementation and aggregation supported by DHTML behaviors. While content authors can create completely new behaviors using plug-ins or OLE, these new behaviors cannot be based on and thus cannot participate with existing behaviors.